虽然Google的MapReduce论文很老了(十多年),但只要还没看,就值得一看。
概要
MapReduce是一种重视容错性的分布式并行计算模式,它把分布式并行计算分为map和reduce两个阶段:
- map: 把输入数据集切分成很多份(1份可包含很多records),传给map函数做转换处理(每次处理1条record,得出1条结果),结果集被输出到文件
- reduce: 读取map的结果集,传给reduce函数做归约处理(每次处理1条record,更新一条共享的结果),结果集被输出到文件
数据通常是key-value格式的,像HashMap,key关联着value。key是连接map和reduce的纽带,reduce通过key来拉取相关的map结果,把关联某个key的一批values归约成一个收敛的结果。
每台机器是一个node。map和reduce都可以在很多worker node上运行。1个任务=1个函数+1组输入数据,任务被分配到worker node上运行。有一个中央的调度器,叫做master node,来进行全局调度,给worker node分配任务。
示意图就不贴了,到处可见的WordCount例子也不写了,别人写过的我一般不写。请参考网络资料。例如这篇就挺好:https://mr-dai.github.io/mapr...
参考好了吗?继续吧!
优化
论文指出它是为大量廉价机器组成的环境而设计的,环境特点是:机器特别多,机器性能参差不齐,有的机器会突然坏掉。论文的很多优化都是在解决这种环境所特有的问题,这在当时是开创性的,因为一般的分布式并行技术都还在研究一组性能均等的高性能机器,不能容忍某台机器变慢或故障。现在工业界都是用MapReduce的方式在搞,因为多数企业的环境都是论文里说的这种。
Google推出MapReduce论文时已经考虑周密了,给出了很多优化点:
Map阶段:
- 一开始先把输入数据集切分成M片,每片一般16~64MB
- map完成时通知master,master记录所有map的完成情况和文件位置
- map tasks要切得小而多,建议远大于机器数,容易负载均衡(3个task分给2个node,均衡度肯定不如13个task分给2个node)
- map tasks尽量分配到靠近数据的node,以节省带宽
- 用combine函数做本地预合并,以减小map的输出结果集
Reduce阶段:
- reducer从mapper node下载输入文件
- reduce先写临时文件,完成时用原子的文件重命名操作
- reduce用lazy iterator读取输入,以节省内存
全阶段:
- map输出到本地文件,reduce输出到全局文件
- map和reduce都可有多个副本同时重复执行,谁快就用谁的结果(即使有个副本突然变慢,也有别的副本在跑)
- 总有一些落后进程,增加百分之几的备用资源,就能加速扫除长尾,节省百分之几十的时间
- 调度器尽量把任务分配给空闲的worker,因此速度快的worker自然会处理更多tasks
- 遇到错误的record,写标记到master,再有task遇到时跳过它
注释:
这种“总有一些落后进程”的现象叫做尾部延迟放大(tail delay amplification),分布式数据库执行查询的scatter/gatter模式也有此问题。
Google的解法相当于task rebalance,来个比喻:让先进员工帮助落后员工完成积压的任务,以保证全团队的项目按时完成。
我们要知道,“计算易移动,数据难移动”,我们总是倾向于把计算移动到另一处,而不是把数据移过去。
MapReduce就是移动了计算,并且把计算尽可能移动到数据附近。task rebalance只移动计算,无需移动数据,所以才管用。
而分布式数据库在执行查询时,把计算分发到data node上,如果有的data node反应慢,就没有办法,因为数据不好移。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。